(1). Field of the Invention
The present invention relates to the field of computer science. More specifically, the present invention relates to modification of data used to configure execution of a computer program.
(2). Art Background
The run-time operation of many computer programs is controlled by user-modifiable program information called "seed data". Seed data is configuration data read during program execution to enable selected program options and, in some cases, to provide an initial set of program data. By modifying seed data, users can upgrade or customize computer programs without having to change program code. The use of seed data is beneficial to both program users and developers. Users can tailor computer programs according to their individual needs, and developers can support various program options without having to provide multiple program versions.
Seed data is typically stored in a relational database or a flat file (e.g., a text or binary file on a local or network disk drive) that can be accessed when program execution begins or later if prompted by a user. In the case of a text-based file, the user can modify seed data with a simple text editor. When seed data is stored in a binary file or in a relational database, a tool is usually provided for inspecting and modifying the seed data.
Despite the benefits of using seed data, there are a number of drawbacks to the way that seed data has traditionally been managed. First, traditional techniques for accessing seed data do not distinguish between different categories of data within an overall set of seed data. It is often desirable to limit access to selected data values of an overall set of seed data so that the selected data values can be modified only by authorized individuals, while other seed data values may be freely modified. However, using the traditional approach, access to seed data is wide open with no provision for limiting access to selected seed data values.
Another problem with the traditional seed data approach is that valid end-user customizations are not preserved during seed data upgrades. During upgrade operations, seed data stored in a flat file or database is often overwritten with new seed data, forcing the user to restore previously entered customization values after the upgrade has been completed. This can be time consuming. In the context of an enterprise-wide upgrade, where end-user seed data customizations must be restored on hundreds or even thousands of machines, the cost of restoring lost seed data can easily outweigh the benefit of the program upgrade.
Another drawback to the traditional seed data approach is that hierarchical protection of seed data is not supported. As a result, seed data customizations can be protected by only one party in a software delivery path; usually the software developer. To appreciate why this is inadequate, consider the following hypothetical software delivery path. A management information systems (MIS) department of an enterprise purchases a computer program and associated seed data from a software developer. For this step in the software delivery path, the software developer is the seed data supplier and the MIS department is the seed data consumer. The MIS department may or may not be able to customize the seed data, depending on whether the developer has protected the seed data from customization. Assume that the seed data is customizable and that the MIS department customizes the seed data according to enterprise needs, then delivers the computer program and customized seed data to a number of customers within the enterprise (e.g., accounting, engineering, sales, etc.). For this step in the software delivery path, the MIS department is the seed data supplier and the enterprise customers are the seed data consumers. Since the MIS department was not able to protect its customizations, each of the enterprise customers is able to overwrite the MIS customizations with their own customizations. This is undesirable, since the MIS-entered customizations may have ensured operational compatibility between the various enterprise customers or served some similar purpose unknown to the enterprise customers. To state the problem generally, without hierarchical protection of seed data, seed data suppliers cannot prevent their seed data customizations from being overwritten by seed data consumers.
It would be desirable to protect seed data according to an access hierarchy so that selected seed data can be protected from modification by seed data consumers and so that valid seed data customizations entered by seed data consumers can be preserved during seed data upgrades.